終於到最後一天了，相信一路這樣下來，大家應該能對 Rive 的理論與實務有一些基本的知識，最後讓我們把這三十天的文章做一點摘要跟總結，幫大家複習一下。

Rive 的介紹 & 優缺點

首先，Rive 是一個 JavaScript 的 library，讓設計師可以做完動畫後，輸出檔案，直接跑在瀏覽器上，不需要像傳統的動畫製作流程，前端還要照著設計手刻一次。這是 Rive 最大的好處，也就是降低製作動畫時，設計師與工程師來回的溝通成本。

除此之外，Rive 可以帶參數給動畫，也可以讓使用者跟動畫互動，這兩者就算不用 Rive 當然也可以做到，但會產生非常大的溝通與實作成本。Rive 提供了一個比較簡單的解決方案，所以其實這兩個優點，本質上是降低溝通成本的延伸。這種成本在健康的公司與環境下不應該太多，但理想終究是理想，所以實務上來說，Rive 的這個優點非常有用。

當然 Rive 也有他的缺點，例如參數的範圍不能太大，不能同時播一段動畫，動畫不能太吃效能，也沒有粒子、光影、或其他 3D 效果。跟其他動畫技術比較的話，Rive 可以比 Lottie 做到更多事情，完全優於雪碧圖、GIF、SVG、影片等比較初階的技術。視覺效果或效能會輸給 Unity, PixiJS, Cocos 等技術，但學習成本比他們少很多。所以平均來說，Rive 是前端動畫最通用的選擇。

Rive 的語法

Rive 的基本語法有 Hello World, State Machines, Rive Text, Rive Events，我們針對這四者寫了一些簡單的範例，如果覺得官方文件寫不清楚的話，不妨參考一下。同時針對怎麼組織程式碼部分，我們也建議盡量把商業邏輯與業務邏輯拆開，再經由物件導向組織起來，同時可以多用 store。Rive 的語法都不難，通常設計模式與觀念會比較重要。

除了基本的 High-level 方式以外，Rive 另外提供了一組 Low-level API，效能跟操控性都比較好，但語法比較難一點。首先我們要有 render loop 的概念，也就是動畫渲染的 init-update-render-cleanup 四個階段，Low-level API 本質上就是在 render loop 的四個階段，分別引用 Rive 官方提供的相對應的 API 而已。State Machines, Rive Text, Rive Events 的語法也跟之前不一樣，我是覺得官方文件寫的不是很清楚，可能直接看文章比較快。

一些進階議題

我們也根據實務上遇到的一些進階議題，做了一些簡單的說明，例如 timer、滑點、Loading Assets、效能最佳化技巧，以及其他我們踩過的雷等等。這些建議很 case by case，再加上 Rive 是一個正在發展中的東西，所以這些建議不一定是最好的。但他們都是我們實務上真正遇到的問題，所以還是有一點參考價值。

最後我們也帶大家看了一些 Rive 作品，並對 Rive 這個新技術做了一點評價。我們認為，Rive 最好的使用情境，是簡單而吸引人的互動動畫，負責在第一時間抓住使用者的注意力。他可能可以拿來做遊戲引擎，但因為相較於其他競爭對手還不夠成熟，所以目前還不建議這樣做。總體來說，Rive 是一門值得投資的動畫技術，但是要小心過度設計的問題，Rive 是用來節省開發成本，創造更多收益用的，不是拿來繼續內捲的。

致謝

以上是這三十天的摘要與總結，不得不說，三十篇文章真的比想像中難寫很多，最後我也藉這個機會，說一點感謝的話。

首先還是要謝謝 Rive 官方團隊，雖然我一直在噴他們的文件寫的很糟，但 Rive 還是解決了很多前端製作動畫的痛點，而且看的出來他們真的有心想發展這個產品，我們幾次跟他們聯絡的感覺都還不錯，希望他們能推出更多功能，然後把文件寫好一點拜偷。

再者要感謝我們的設計師大大們，好吧我也不否認我常常在文章中偷臭設計師，但那是針對設計師這個群體而不是個人但絕大部分的時候我們的設計師團隊都非常優秀，他們提供了非常多優質的素材給我，無論是平常做專案還是這次寫文章🙈🙈🙈。而且憑良心講，我有信心比起一般的團隊來說，我們的設計師大大們已經是相對好溝通的那一邊了，能力更是遠超過我遇過的 95% 以上的設計師，所以有時候我寫文章也抖抖的，怕我講得太凶讓大家誤會。總之沒有他們的話，我絕對無法完成這次的鐵人賽，再次感謝他們。

最後要感謝兩位前端好朋朋，這三十篇文章吸收了很多他們的意見，他們也願意在我出國時幫我上傳文章，平常工作的能力與態度也是完全沒話說，都已經是可以獨挑大樑的前端工程師了。謝謝你們，未來也請多指教。

以上就是這次的鐵人賽，關於 Rive 的理論與實務。